Description

This PR introduces:

• Weighted chain comparisons: We compare chains based on their weight instead of their length. Non-trivial weight is given by Peras certificates as introduced in [Peras 1] Introduce basic types to support Peras #1673.
• Weighted chain selection: Select the weightiest chain instead of the longest chain.
• Weighted immutability criterion: Define the immutable tip in terms of weight instead of length.

Commits

The commits are intended to be reviewed individually:

• ChainDB: expose PerasCertDB functionality

  The ChainDB maintains a PerasCertDB internally, and exposes most of its functionality through its public API. This is analogous to how the LedgerDB is managed by the ChainDB.

• SecurityParam: mention weighted nature

  Purely a documentation update to mention the richer dynamics under Peras, plus a small helper function.

• O.C.Peras.Weight: add takeVolatileSuffix

  In Praos, the volatile suffix of a chain is defined to be the k most recent blocks. Analogously, in Peras, the volatile suffix of a chain is defined to be the longest suffix with weight at most k.

  This commits adds an appropriate function (via a binary search), as well as documentation and tests.

• ChainDB: define getCurrentChain in terms of weight

  This makes use of the previous commit in the ChainDB. Note that Minimize exposure to exact immutability criterion #1619 guarantees that the LedgerDB automatically uses the same notion of immutability.

  Note that this means that the immutable tip will be less than k blocks behind the tip when Peras is working well, ie every Peras round is giving rise to a certificate. Concretely, for plausible parameters, ie a round length of $U = 90$ slots and a Peras boost of $B = 15$, the length of the volatile suffix decreases from $k=2160$ to

  $$\frac{k}{1+\frac{B}{U\cdot f}} \approx 499$$

  on average.

• ChainDB.StateMachine: check immutable tip monotonicity

  To make sure that the more refined immutability criterion doesn't introduce any surprises, we add a postcondition to the ChainDB q-s-m test that the immutable tip never recedes.

• GSM: allow candidateOverSelection to be stateful and ChainSel: make rollbackExceedsSuffix weight-aware

  Preparatory refactorings for when the chain comparison will become weighted and hence additionally depend on the PerasWeightSnapshot.

• Peras.SelectView: initialize, expose WeightedSelectView

  This introduces the notion of a weighted SelectView, making use of Refactor: SelectView = BlockNo × TiebreakerView #1591

  ouroboros-consensus/ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Peras/SelectView.hs

  Lines 35 to 48 in 90131b2

  	-- | Information from a non-empty chain fragment for a weighted chain comparison
  	-- against other fragments with the same anchor.
  	data WeightedSelectView proto = WeightedSelectView
  	{ wsvLength :: !Word64
  	-- ^ The length of the fragment.
  	--
  	-- If we ignore EBBs, then it would be equivalent to use the tip 'BlockNo'
  	-- here. However, with EBBs, the 'BlockNo' can result in misleading
  	-- comparisons if only one fragment contains EBBs.
  	, wsvWeightBoost :: !PerasWeight
  	-- ^ The weight boost of a fragment (w.r.t. a particular anchor).
  	, wsvTiebreaker :: TiebreakerView proto
  	-- ^ Lazy because it is only needed when 'wsvTotalWeight' is inconclusive.
  	}

  This will used in place of the "normal" SelectView. Eventually, we could also remove the normal SelectView and replace it with WeightedSelectView. However, to keep this already big PR more focused, we propose to do this in the future.

• Introduce weighted chain comparisons

  The core change in this commit is in the O.C.Util.AnchoredFragment to the preferAnchoredCandidate and compareAnchoredFragments functions. These now

  • have a slightly strengthened precondition, namely that they intersect (as we otherwise can't meaningfully compare their weight), that we ensure is satisfied anywhere, and
  • take PerasWeightSnapshot as an additional argument.

  We keep the old implementation in case the PerasWeightSnapshot is empty; which is semantically unnecessary, but is a trivial way to make sure that no performance regression is introduced.

  The rest of the diff of this commit is simply due to adapting the respective call sites in a rather straightforward fashion.

• Integrate weighted BlockFetch decision logic

  This commit plugs the weighted chain comparison logic into the BlockFetch decision logic. This relies on a (merged, but not yet released, hence the s-r-p) Network change, see Support weighted chain comparisons ouroboros-network#5161 for a detailed description.

• ChainDB: implement chain selection for Peras certificates

  We allow new Peras certificates to be added to the ChainDB (and therefore to the managed PerasCertDB). If the certificate is boosting a block that is not on the current selection, we perform chain selection for it, potentially switching to a fork containing it if it now is weightier than our selection.

• MockChainSel: switch to weighted chain selection

  This logic is for example used in tests.

• ChainDB q-s-m: test weighted chain selection

  We enrich the model ChainDB implementation with weighted chain selection, and add a new command with a simple generator for adding certificates. We also enrich labelling with the TagSwitchedToShorterChain tag that shows that we sometimes do switch to a shorter chain; which would be a bug without Peras.

  A follow-up PR (Better certificate generation in ChainDB q-s-m test #1670) will further improve the generators of this test.

Regression

As of today, there is no way to generate certificates, so PerasCertDB is always empty, and the change to the chain selection algorithm is therefore invisible: in the absence of certificates, the Peras weight of a chain is equal to its length. Therefore, this PR does not introduce any semantic changes.

Furthermore, from a performance standpoint, care is taken to ensure that if there are no certificates, we use the unweighted Praos logic, meaning that there is no change in performance when Peras is disabled.